¿Es posible tener dos clases parciales en diferentes ensamblados que representan la misma clase?

Tengo una clase llamada 'Artículo' en un proyecto llamado 'MyProject.Data', que actúa como la capa de datos para mi aplicación web.

Tengo un proyecto separado llamado 'MyProject.Admin', que es un sistema de administración basado en la web para ver / editar los datos, y fue construido usando ASP.NET Dynamic Data.

Básicamente, quiero extender la clase Article, usando una clase parcial, para poder aumentar una de sus propiedades con un extensor "UIHint", lo que me permitirá reemplazar el cuadro de texto normal de varias líneas con un control FCKEdit.

Mi clase parcial y extensor se verían así:

[MetadataType(typeof(ProjectMetaData))]
public partial class Project
{
}

public class ProjectMetaData
{
    [UIHint("FCKeditor")]
    public object ItemDetails { get; set; }
}

Ahora todo esto funciona bien si la clase parcial está en el mismo proyecto que la clase parcial original, es decir, el proyecto MyProject.Data.

Pero el comportamiento de la interfaz de usuario no debería estar en la capa de datos, sino en la capa de administración. Entonces quiero mover esta clase a MyProject.Admin.

Sin embargo, si hago eso, la funcionalidad se pierde.

Mi pregunta fundamental es: ¿puedo tener 2 clases parciales en proyectos separados, pero ambas se refieren a la misma "clase"?

Si no, ¿hay alguna manera de lograr lo que estoy tratando de hacer, sin mezclar la lógica de la capa de datos con la lógica de la interfaz de usuario?

No, no puede tener dos clases parciales que se refieran a la misma clase en dos ensamblajes (proyectos) diferentes. Una vez que se compila el ensamblado, los metadatos se incorporan y sus clases ya no son parciales. Las clases parciales le permiten dividir la definición de la misma clase en dos archivos.

Como se señaló, las clases parciales son un fenómeno de tiempo de compilación, no tiempo de ejecución. Las clases en los ensambles son, por definición, completas.

En términos de MVC, desea mantener el código de vista separado del código del modelo, pero habilitar ciertos tipos de IU basados ​​en las propiedades del modelo. Echa un vistazo a la excelente descripción de Martin Fowler de los diferentes sabores de MVC, MVP y otras cosas: encontrarás muchas ideas de diseño. Supongo que también podría usar la Inyección de dependencias para decirle a la IU qué tipo de controles son viables para entidades y atributos individuales.

Su objetivo de separar las preocupaciones es excelente; pero las clases parciales estaban destinadas a abordar problemas completamente diferentes (principalmente con la generación de código y los lenguajes de modelado en tiempo de diseño).

Los métodos de extensión y ViewModels son la forma estándar de extender objetos de capa de datos en la interfaz de la siguiente manera:

Capa de datos (biblioteca de clases, Person.cs):

namespace MyProject.Data.BusinessObjects
{
  public class Person
  {
    public string Name {get; set;}
    public string Surname {get; set;}
    public string Details {get; set;}
  }
}

Display Layer (aplicación web) PersonExtensions.cs:

using Data.BusinessObjects
namespace MyProject.Admin.Extensions
{
  public static class PersonExtensions
  {
    public static HtmlString GetFormattedName(this Person person)
    {
       return new HtmlString(person.Name + " <b>" + person.Surname</b>);
    }
  }
}

ViewModel (para datos específicos de vista extendida):

using Data.BusinessObjects
namespace MyProject.Admin.ViewModels
{
  public static class PersonViewModel
  {
    public Person Data {get; set;}
    public Dictionary<string,string> MetaData {get; set;}

    [UIHint("FCKeditor")]
    public object PersonDetails { get { return Data.Details; } set {Data.Details = value;} }
  }
}

Controller PersonController.cs:

public ActionMethod Person(int id)
{
  var model = new PersonViewModel();
  model.Data = MyDataProvider.GetPersonById(id);
  model.MetaData = MyDataProvider.GetPersonMetaData(id);

  return View(model);
}

Ver, Person.cshtml:

@using MyProject.Admin.Extensions

<h1>@Model.Data.GetFormattedName()</h1>
<img src="~/Images/People/image_@(Model.MetaData["image"]).png" >
<ul>
  <li>@Model.MetaData["comments"]</li>
  <li>@Model.MetaData["employer_comments"]</li>
</ul>
@Html.EditorFor(m => m.PersonDetails)

Agregue el archivo base como un archivo vinculado en sus proyectos. Todavía es parcial, pero le permite compartirlo entre ambos proyectos, mantenerlos sincronizados y al mismo tiempo tener un código específico de versión / marco en las clases parciales.

He tenido problemas similares con esto. Mantuve mis clases parciales en mi proyecto de datos, así que en su caso el 'MyProject.Data'. MetaDataClasses no debe ir en su proyecto de administración, ya que de lo contrario creará referencias circulares.

Agregué un nuevo proyecto Class Lib para mis MetaDataClasses, por ejemplo, 'MyProject.MetaData' y luego hice referencia a esto desde mi proyecto de datos

Quizás use una clase de extensión estática.

Puedo estar equivocado aquí, pero ¿no podría simplemente definir la clase ProjectMetaData en su proyecto MyProject.Admin?

Simplemente agregue el archivo de clase como enlace en su nuevo proyecto y mantenga el mismo espacio de nombres en su clase parcial.

Desde 2019, puede tener 2 partes de una clase parcial en diferentes ensamblajes utilizando un truco. Este truco se explica y se demuestra en este artículo:

https://www.notion.so/vapolia/Secret-feature-Xamarin-Forms-control-s-auto-registration-1fd6f1b0d98d4aabb2defa0eb14961fa

Utiliza en su núcleo la extensión MSBuild.Sdk.Extras para proyectos similares a SDK, que resuelve la limitación de tener todas las partes parciales de una clase en el mismo ensamblaje, mediante el uso de un proyecto con múltiples destinos simultáneos, creando efectivamente ensambles múltiples en una compilación del mismo proyecto.