В приложении N-уровня предполагается наличие уровня бизнес-логики и уровня доступа к данным.
Разве плохо иметь две сборки: BusinessLogicLayer.dll и DataAccessLayer.dll для обработки всей этой логики? Как вы на самом деле представляете эти слои. На мой взгляд, глупо иметь библиотеку классов BusinessLogic, содержащую такие классы, как: CustomerBusinessLogic.cs, OrderBusinessLogic.cs и т. Д., Каждый из которых вызывает своего кузена с соответствующим именем в библиотеке классов DataAccessLayer, т.е. CustomerDataAccess.cs, OrderDataAccess. .cs.
Я хочу создать веб-приложение с использованием MVP, и оно не выглядит таким скучным, как это. Есть много мнений о том, где бизнес-логика должна быть заложена в MVP, и я не уверен, что нашел действительно хороший ответ.
Я хочу, чтобы этот проект был легко тестируемым, и я стараюсь придерживаться методологий TDD как можно лучше. Я собираюсь использовать MSTest и Rhino Mocks для тестирования.
Я думал о чем-то вроде следующего для моей архитектуры:
Я бы использовал LINQ-To-SQL для связи с базой данных. Службы WCF для определения интерфейсов контрактов данных для уровня бизнес-логики. Затем используйте MVP с ASP.NET Forms для пользовательского интерфейса / BLL.
Теперь, это не начало этого проекта, большинство вещей LINQ уже сделано, поэтому оно застряло. Служба WCF заменит существующую сборку DataAccessLayer, а пользовательский интерфейс / BLL заменит сборку BusinessLogicLayer и т. Д.
Этот тип имеет смысл в моей голове, но становится очень поздно. У кого-нибудь, кто путешествовал по этому пути, есть какое-нибудь руководство? Хорошие ссылки? Предупреждения?
Спасибо!